home *** CD-ROM | disk | FTP | other *** search
/ Collection of Internet / Collection of Internet.iso / infosrvr / dev / www_talk.930 / 001225_weber@eitech.com _Tue Jun 1 19:39:15 1993.msg < prev    next >
Internet Message Format  |  1994-01-24  |  2KB
  1. Return-Path: <weber@eitech.com>
  2. Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  3.     id AA02131; Tue, 1 Jun 93 19:39:15 MET DST
  4. Received: from lks.lks.csi.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
  5.     id AA13237; Tue, 1 Jun 1993 19:59:22 +0200
  6. Received: from eitech.eitech.com by lks.lks.csi.com (5.65/6.930123)
  7.      with SMTP id AA23480; Tue, 1 Jun 93 12:58:05 -0500
  8. Received: from bd.eitech.com ([192.100.58.27]) by eitech.com (4.1/SMI-4.1)
  9.     id AA05255; Tue, 1 Jun 93 10:52:37 PDT
  10. Message-Id: <9306011752.AA05255@eitech.com>
  11. X-Sender: weber@eitech
  12. Date: Tue, 01 Jun 1993 10:58:22 -0800
  13. To: Dave_Raggett <dsr@hplb.hpl.hp.com>
  14. From: weber@eitech.com (Jay Weber)
  15. Subject: Re: More than just HTML (was Re: Poetry and Maths)
  16. Cc: www-talk@nxoc01.cern.ch
  17. X-Mailer: <PC Eudora Version 1.1a5>
  18.  
  19. At 03:05 PM 6/1/93 BST, Dave_Raggett wrote:
  20. >>> The embedded data can
  21. >>> be sent along with the main document using MIME's multipart capability.
  22. >
  23. >> How do you plan on doing this in HTML+?  Sounds like the first part
  24. >> will be text/html, where the anchors reference other parts.  The reference
  25. >> can be done by defining a URL access type of "part", e.g. HREF=part:XXX
  26. >> where XXX is a Content-id.
  27. >
  28. >I think that the HREFs should use the standard URL for the document, and the
  29. >MIME subheader for the image (or whatever) should include a field specifying
  30. >the URL for the subpart, e.g.
  31. >
  32. >        Source: http://info.cern.ch/hyptext/WWW/lep.jpg
  33.  
  34. Good idea, this is much better than a "part" access type.
  35.  
  36. >The current spec for the HTTP doesn't give a suitable field, although
  37. >Message-id is a near miss (defined according to RFC 850).
  38.  
  39. Is it a near-miss because of special characters?  I.e., the content-id
  40. of a part uses the same syntax as a message-id, which must be
  41.  
  42.    "<" local-part "@" domain ">"
  43.  
  44. The local-part is just a dot-separated series of words which must be
  45. unique for that domain.  So if the entire content-id is not suitable
  46. as a field in an URL, we can just use the local-part; it will still
  47. be straightforward for the server to resolve which MIME-part is being
  48. addressed.
  49.  
  50. Jay Weber
  51. EIT
  52.